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Abstract — Papers published via IEEE and AIAA conferences 
have presented an overview of how social media could benefit 
NASA working environments in general [1] and proposed 
three specific social applications to benefit space flight control 
operations [2]. One of them, Communications Dashboard, 
would help a real time flight controller keep up with both the 
“big picture” and significant details of operations via a 
cohesive interface similar to those of social networking services 
(SNS). Instead of recreational social features, “CommDash” 
would support functions like console logging, categorized and 
threaded text chat streams with enhanced accountability and 
graphics display features, high-level status displays driven by 
telemetry or other events, and an on-screen hailing function for 
requesting voice or text stream conversation. Moving certain 
voice conversations to text streams would reduce confusion and 
stress in two ways. Within text conversations, there would be 
far less repetition of content since text conversations have 
visual persistence and are reviewable instantly, e.g., there’s no 
need to brief new participants to a discussion - they just read 
what’s already there. Remaining voice traffic would stand out 
more clearly, and quieter voice loops means fewer “say again” 
calls and less distraction from visual and mental tasks, thus 
less stress. (Most flight controllers monitor 4 or 5 voice loops at 
once.) Links could be created from console log entries to chat 
selections so that underlying details are readily available yet 
unobtrusive. This would reduce the confusion that rises from 
having multiple and sometimes divergent copies of the same 
information due to cut/copy and paste operations, attachments, 
and asynchronous editing. This concept could apply to a 
plethora of real time control environments and to other 
settings with lots of information juggling. This paper explores 
the dashboard concept in further detail and chronicles the first 
phase of a NASA IT Labs (Information Technology) project 
that could lead to a working system. 1 
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1. Introduction 

The heart of International Space Station (ISS) flight 
operations control involves a) communicating effectively in 
real time with other controllers in the room and/or in remote 
locations and b) tracking significant events, decisions, and 
rationale to support the next set of decisions, provide a 
thorough shift handover, and trouble shoo t/improve 
operations. ISS flight controllers speak with each other via 
multiple voice circuits or “loops,” each with a particular 
purpose and constituency. Controllers monitor and/or 
respond to several loops concurrently. The primary tracking 
tools are console logs, traditionally kept by a single operator 
and not visible to others in real-time. Information from 
telemetry, commanding, and planning systems also plays 
into decision-making. Email is very secondary/tertiary due 
to timing and archival considerations and the ease with 
which content can be misplaced or deleted. Voice 
communications and log entries supporting ISS operations 
have increased by orders of magnitude because the number 
of control centers, flight crew, and payload operations have 
grown. A flight controller’s “juggling capacity” can be 
saturated by excessive voice traffic and/or demands from 
other systems, especially during high tempo operations 
when saturation is least affordable. 

While gathering software requirements for a web-based 
console logging application to support ISS payload 
operations at Marshall Space Flight Center’s (MSFC) 
Payload Operations Integration Center (POIC), the author 
noted that text and attachments are often replicated among 
several systems and that much voice traffic involved 
coordination of sending and receiving legacy type 
communications. He also observed that Facebook® and 
other SNSs do an amazing job of a) integrating information 
and processes relevant to their intended audiences and 
purposes and b) helping users spend much more time 
engaging with message content than fighting the addressing 
and indexing scheme. From there, it was a short jump to the 
question, “Why not harness the same kind of streamlining 
power to operations?” The follow-on question, “How could 
we do this?” led to the Communications Dashboard concept. 

Throughout this paper, “Communications Dashboard” will 
frequently be abbreviated as “CommDash”. 

Before delving into the technical particulars of CommDash, 
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let’s look at the project environment in which it’s being 
developed, and some fundamental characteristics of social 
media and how information is transmitted among humans. 

2. NASA IT Labs Project Description 

In July of 2012, the author received approval and funding to 
pursue development of a Communications Dashboard via 
the “IT Labs” (Information Technology) program 


sponsored by NASA’s Chief Technology Officer (CTO), 
with the effort beginning in September 2012. The IT Labs 
approach involves a sequence of 90-to-120 day phases 
managed by update-evaluate-approve-perform-evaluate- 
decide cycles. Each phase is eligible for up to 
approximately $30K of procurement funds. Figure 1 
illustrates the IT Labs project flow: 
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Idea/Issue - Exploration of a capability or technology that has potentially 
significant value to users 
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Figure 1 - NASA IT Labs Project Flow 


The IT Labs application process requires submitting a video 
of a one-minute “elevator pitch” outlining the project. The 
pitch for CommDash is viewable online at 

http://av.ndc.nasa.gov/content/download2.php?video=Dave 
ScottCommunications . One might find it helpful to pause 
the video at various points to ponder slide contents. 

The CommDash project’s primary goal is to build a 
software test bed to explore unconventional integration, 
presentation, and exchange of flight control communications 
in intra-center and/or inter-center contexts. The ultimate 
goal is to create a unified interface for multiple 
communication tools to complement and/or augment voice 
loop discussions. This would enable flight controllers to 
manage more operations with fewer spoken and written 
words and with greatly reduced stress. 

Secondary results might include a) new SNS methods 
and/or unique mash-ups of existing techniques and b) 
techniques that could apply to a wide variety of control and 
design environments. 

The approach to the Idea/Issue phase is: 

• Seek flight control facility developers at other NASA 
centers and perhaps a few other agencies. Look for 
similar interests and concerns. Evolve ideas on what 


capabilities to strive for in the testbed. 

• Identify and assess COTS/Open Source component 
potential for creating the types of features envisioned in 
the elevator pitch. 

• Develop preliminary ideas on how existing flight 
control applications at MSFC’s HOSC could provide 
selected data for presentation in a Comm Dashboard. 

• Define a target scope and extent for the Proof of 
Concept phase effort. 

NASA IT Labs provides a Sharepoint®-based management 
and collaboration web site to each project. These are 
accessible by those with regular or VPN access to the 
NASA institutional network. CommDash’ s site is at 
https://labs.nasa.gov/Communication Dashboard . 

While NASA personnel supporting this effort clearly have 
access, many of the information and expertise sources that 
can make CommDash a reality lie outside the NASA 
network. This barrier turned out to be benevolent in nature, 
as it prompted the author to practice what he preaches about 
using social media in the workplace. (Segue to next 
section!) 
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3. Collaborative Paths 


The IT Labs program provides a well-organized web page 
for each project, with flexible layout options that the 
Pi/project manager can exercise. Sections include project 
status, milestones, calendar, discussions with 
sponsors/management, links, document library, and 
discussions among participants. The last two sections 
presented a challenge in that some members of the the team, 
which includes representatives from multiple NASA field 
centers, Commercial Off The Shelf (COTS) vendors, and 
Open Source software providers, cannot access the NASA 
network. 

As it happens, the author had established a Wiki for follow- 
on discussions related to the SpaceOps 2012 paper [2] that 
discussed CommDash and two other ways to simplify 
control room communications. This presented an 
opportunity to feed two birds with one crumb. By hosting 
discussions on the “Simplify Ops Comm” wiki, current 
CommDash participants could interact with one another and 
those following the wiki courtesy of SpaceOps or other 
referrals might become interested and join the team. 
“Discoverability” is a key attribute of Web 2.0 and social 
media [1]. 


The now-traditional practice of collaboration via emailing, 
posting, downloading, and uploading document files was a 
big improvement over circulating paper, especially where 
distance was an issue, and has also created tremendous file 
proliferation problems, just as cutting and pasting among 
console logs, planning systems, and the like has cluttered 
the operations world. NASA recently extended their pilot of 
Google Apps for NASA, which stores NASA-originated 
files in a government cloud yet allows easy access by 
invited internal or external parties. Storing CommDash 
documents there, then publishing links to these Docs on the 
IT Labs CommDash site and the Simplify Ops Com wiki 
means there is one copy for all to share. Additional 
productivity and clarity comes from Google Docs’ 
collaborative editing capability (simultaneous and 
asynchronous collaborative commenting and editing per 
document owner’s assignment). 

Figure 2 shows the “triple play” structure intended for 
CommDash collaboration. Due to discoveries made shortly 
before publication deadline, changes are in work to host the 
public-facing forum via Google Apps for NASA instead of 
wikispaces.com. 



Figure 2 - Collaboration Paths 


4. Social Media Underpinnings 

For several years, social media carried a connotation of 
mere recreational friendship. As blogs and SNSs have 
become more common in offices, this negative image has 
diminished somewhat. If we define “social” as “interactions 
among organisms and their systems,” it’s logical that the 


engineering and operations world would pay as much 
attention to social interfaces among humans as we pay to 
those among our electronic systems. Figure 3, which was 
adapted from presentation charts related to earlier papers [1] 
and [2], reviews some social media principles , behaviors, 
and potentials that relate particularly well to CommDash. 
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Cut away clutter so content can be seen. 


Blogs and/or chat streams make text discussions cohesive 



Central logs / multi-author blogs; improve sync, reduce voice traffic 



Separate capture scatters, 
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Figure 3 - Some Operations-Relevant Social Media Functional Characteristics and Behaviors 


5. Critical Concept - Visual Persistence 

When the space program began, voice communication was 
much easier to create and transmit than text or graphics - we 
were using paper, pencils/pens, and typewriters! While 
computers sped up the business of creating text and graphics 
decades ago, developments in the last few years have 
enabled text and graphics to become nearly self-managing, 
making them easier to manage and follow than voice 
CommDash relies heavily on the principles illustrated in 
Figure 4. 
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Text/Graphics 



Semi-Parallel / Parallel 
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Slower to create than voice 
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Figure 4 - Comparative Characteristics of 
Voice and Text/Graphics 



6. Communications Dashboard Overview 


Since a Social Networking Service (SNS) approach has 
been chosen as the basis for CommDash and since most 
people with internet access are at least familiar with a 
leading SNS such as Facebook® or Linkedln®, perhaps the 
easiest way to describe CommDash’ s intended functionality 
is via the visual mockup shown in Figure 5. 


Note - This discussion assumes that he reader is familiar 
with ISS Operations Protocol and/or aviation voice protocol, 
e.g., standard phrasing conventions for verbal and written 
communications in the real time flight control environment. 
Translations of acronyms referring to flight controller 
positions, systems, payloads, and statuses are generally not 
given, as they are not central to how the components work. 


Voice traffic related to chat: 

025/1510 PAYCOM and PSE. POD on POD loop: Could you work situation ABC and summarize on this loop when finished? 
PAYCOM: Wilco - PSE. meet me on PAYCOM chat? PSE: Wilco. 

025/1525 POD. PAYCOM on POD loop: We’ve finished working ABC. and recommend DEF because of GHI. 

POD: Thanks. PAYCOM and PSE. I’ll discuss with FLIGHT and get back with you. 

(Interested parties can review the detailed discussion by viewing the PAYCOM chat channel between 1510 and 1525.) 
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Figure 5 - Communications Dashboard Mockup Based on ISS Payload Operations at POIC 

7. Technical Progress to Date 


Figure 6 shows a first-cut breakdown of information stream 
sources and likely integration functions that CommDash 
would need to provide. 


There have been preliminary discussions with a few COTS 
vendors, and some of their product features have provided 
food for thought. 
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Figure 6 - Preliminary Breakout of CommDash Functions 


To be effective in an operations environment, CommDash 
should have some unique features compared to most of 
today’s SNS environments: 

• Resize individual frames, perhaps by dragging borders 

• Rearrange relative location of frames (some SNSs 
allow this, but with significant restrictions) 

• View multiple chat streams concurrently 

• Swap out chat streams very quickly and simply 

• Create dedicated chat streams on-the-fly, e.g., for a 
specific discussion (as opposed to a stream analogous to 
a given voice loop) 

• Dynamically manage chat streams, e.g., restrict access, 
lock a stream temporarily or permanently 

• Index streams, e.g., list in a filterable table of contents 
similar in appearance to email environments 

Candidate Alert & Pulldown functions (analogous to 
Facebook® Friend Request, Messages, and Notifications 
alerts) might include console e-mail account access, 
individual company e-mail account access, hailing, user- 
defined notifications/reminders, etc. 

User interface design merits extremely careful thought and 
consideration. 


8. Conclusion 

The author has used this Idea/Issue phase to assemble a 
team representing multiple control center interests at NASA 
and to gather preliminary inputs from government and 
industry on existing tools that might be brought to bear. 

Current state-of-the-industry technology appears to be 
sufficient to build the target environment. Innovation will 
lie in the way that the pieces are assembled. 

The author will apply to NASA IT Labs for a follow-on 
Proof of Concept phase to define underlying detail and test 
some components sufficiently to justify proceeding to the 
Prototype phase, with MSFC’s POIC being the target 
environment. By accounting for interests across the agency 
up front, it should be possible to design and build a robust 
testbed and/or prototype that could be easily refined and 
adapted to other control centers, NASA functions, and/or 
industries. 

A collaborative environment that is discoverable by anyone 
and that allows in-depth browsing and contributions by 
approved contributors is invaluable for a) involving a broad 
spectrum of participants across government, academia, and 
industry and b) minimizing redundancy. The resulting team 
may be useful for pursuits beyond the original project. 
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It’s worth noting that JSC is working on a demonstration of 
text chat capability between ISS and the ground. The 
CommDash team hopes that we might join forces at an 
appropriate time. 

The one-minute “elevator pitch” video required as part of 
the IT Labs application process was extremely valuable. The 
video itself concisely defined and illustrated the proposal, 
while the effort to create the video focused the author! This 
would be a good exercise for a wide variety of proposal 
efforts. 

While CommDash has been conceived with mission 
operations in mind, a very similar treatment could be quite 
effective for mission support and/or large scale design 
projects... Space Launch System, perhaps? 

If all goes well, Chapters 2 and perhaps 3 of this effort will 
appear at future conferences. Feel free to contact the author 
and join the team! 
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